Release 10.1A: OpenEdge Data Management:
Database Administration

Two-phase commit case study

This case study illustrates the process of resolving a limbo transaction. It involves two databases, sports1 and sports2, located on separate machines, mach1 and mach2, respectively. Each database has two-phase commit enabled and each has a server running against it. The coordinator database is sports1.

Suppose that you start a client process on mach1 against the sports1 database and then connect to the sports2 database using this command:

CONNECT sports2 -H mach2 -S sportssv

After connecting, you try to run a distributed transaction. While running this procedure, the client process is halted by a system error, and the following messages appear:

Error reading socket, ret=-1, errno=2. (778) Part of the distributed transaction might have failed. (2022) Press space bar to continue.

The message indicates that a limbo transaction might have occurred. You must determine whether a limbo transaction did occur, then resolve it.

You start PROMON against sports1, choose T (Transaction Control), and choose 1 (Display all entries). This screen appears, indicating that there are no limbo transactions on sports1:

Transaction Control: Usr Name  Trans  Login  Time  R-comm?  Limbo?  Crd?  Coord  Crd-task RETURN - repeat, U - continue uninterrupted, Q - quit:

If PROMON failed to run against sports1, it indicates that the server also crashed and you must use PROUTIL to determine whether any limbo transactions occurred.

After determining that no limbo transactions occurred on sports1, perform the same steps against sports2. This time, the following screen appears, indicating that a limbo transaction has occurred:

Transaction Control: Usr Name  Trans  Login  Time  R-comm?  Limbo?  Crd?  Coord  Crd-task  15 paul  755  04/01/02 14:19  yes      yes     no  sports1  61061                      .                      .                      . RETURN - repeat, U - continue uninterrupted, Q - quit

Write down the coordinator’s transaction number (indicated in the Crd-task field). The Coord field indicates that sports1 is the coordinator database for this transaction. Therefore, you must again run PROMON against sports1. This time, choose C (Coordinator Information). The following screen appears, where you enter the transaction number 61061:

PROGRESS MONITOR Release 10.0A    Database: /users/sports1    Q. QUIT Enter the transaction number you want to find out if committed: 61061

The following screen appears, indicating that the transaction committed:

Scan the logs... ** Transaction 61061 has committed. Q. QUIT Enter the transaction number you want to find out if committed:

Since the transaction committed on the coordinator sports1, you run PROMON against sports2 and choose 1 (Resolve Limbo Transactions). The following screen appears:

Transaction Control: Usr   PID  Time of Login            User ID  TTY         Coord  Crd-task  15  3308  Fri Apr 5 14:19:45 2002  paul   mach1 ttyp1  sports1   61061      1 Abort a Limbo Transaction      2 Commit a limbo Transaction      Q Quit Enter choice>

Choose 2 (Commit a Limbo Transaction), and this prompt appears:

Enter the user number whose transaction you want to commit:

Type 15 (the user number indicated on the previous screen). The PROMON utility commits the transaction on sports2 and displays this message:

User 15: commit transaction and disconnect.

Since there are no more limbo transactions, the situation is resolved and no further action is required.